【レポート】ECS Service Connect で ECS 上のマイクロサービスの耐障害性と可観測性を高めよう

こんにちは！AWS事業本部のおつまみです！

本記事は 2023 年 4 月 20 - 21 日の 2 日間開催された AWS Summit Tokyoのセッションレポートとなります。

AWS Summit Tokyoの登録を行うことで、2023 年 6 月 23 日 19 時までオンデマンドで視聴可能です。（現地参加された方は改めての登録は不要です。）

ECS Service Connect についてはこちらのブログでも紹介されています。

セッション概要

Amazon ECS 及び AWS Fargate では新しいサービス間通信の方式として、ECS Service Connect を AWS re:Invent 2022 でリリースしました。ECS Service Connect を利用することで、これまでより容易にサービス間の耐障害性や可観測性を高めることが可能となります。本セッションではこれまでのサービス間通信の方式と課題、ECS Service Connect が実現できることについて解説します。

スピーカー

アマゾン ウェブ サービス ジャパン合同会社技術統括本部
インターネットメディアソリューショングループ ソリューションアーキテクト　堀内 保大

はじめに

本セッションの対象となる方

• コンテナやAmazon Elastic Container Service (Amazon ECS) について概要を理解している
• Amazon ECS 上でマイクロサービスを構築したいと思っている方
• Amazon ECS における耐障害性や可観測性の確保に興味のある方

本セッションのゴール

• Amazon ECS におけるサービス間通信の課題、実現の選択肢を理解できるようになる
• ECS Service Connect のユースケースやメリットを理解できるようになる

アジェンダ

1. コンテナとAWSのコンテナサービスのメリット振り返り
2. マイクロサービスとサービス間通信の課題や実現方法
3. Amazon ECS Service Connect 概要
4. Amazon ECS Service Connect Dive Deep
5. まとめ

レポート

コンテナとAWSのコンテナサービスのメリットと振り返り

企業がコンテナサービスを採用する背景

• スピードとアジリティ
• 運用の優秀性とセキュリティ
• コスト

コンテナがもたらすメリット

• アプリケーションの可搬性
• 複数環境にわたる一貫した実行可能性
• 高速な開発とリリースサイクルの実現
• サーバレスファーストでよりシンプルにコンテナを実行
• ECS・Fargateにより高い抽象化とインフラ管理工数の低減アプリケーション開発に注力できるようになる

マイクロサービスとサービス間通信の課題や実現背景

• マイクロサービスによる開発アジリティの向上
  • 独立した複数のサービスでソフトウェアを構成する
  • ビジネスドメインごとにサービスを分割し疎結合する
  • アプリケーションが複数のサービス

サービス間通信の信頼性を高める工夫 1.耐障害性

• NWのエラーや遅延、 呼出先の不具合/停止に対する耐障害性の仕組みが必要
  • 呼出先サービスの位置は一定でない → サービスディスカバリ
  • 一時的な呼び出しの失敗 → リトライ (Exponential back-off) 外れ値検知
  • 継続した呼び出しの失敗 → サーキットブレーカー
  • 呼出先サービスのパフォーマンス悪化 → タイムアウト

サービス間通信の信頼性を高める工夫 2.可観測性

• どこで何が起きたのか、 なぜ起きたのか調査するために、可観測性を高める仕組みが必要
  • 各サービスのメトリクス・ログ・トレースの取得

これまでのサービス間通信の選択肢

• ロードバランサ有
  • Elastic Load Balancing (ELB)
• ロードバランサ無
  • ECS service discovery
  • AWS App Mesh

Elastic Load Balancing (ELB)の利用

• メリット
  • ヘルスチェックなどのさまざまな機能セットを有する
  • トラフィックのメトリクスを取得できる
• 考慮点
  • 追加のインフラストラクチャが必要となる
  • ネットワークレイテンシーが増加する
  • ヘルスチェックに依存する

Amazon ECS service discoveryの利用

• メリット
  • クライアントが対向サービスと直接通信する
  • 少数のシステムコンポーネントで構成できる
• 考慮点
  • リトライ、外れ値検知などの信頼性を保つ通信制御・トラフィックのメトリクス取得などは含まれない

AWS App Mesh の利用

• メリット
  • リトライ、外れ値検知、 サーキットブレーカー、タイムアウトなどのきめ細かいトラフィックの制御が可能
  • メトリクス、ログ、 トレースなどのトラフィックの豊富な可観測性をもつ
• 考慮点
  • 追加のコンポーネントの管理が必要となる
  • 柔軟性に伴う複雑性が増す

Amazon ECS Service Connect 概要

特徴

• サービス間通信における考慮事項が追加設定なしに組み込まれる
  • 耐障害性
  • 可観測性
  • 堅牢なデプロイ

Amazon ECS Service Connect Dive Deep

メリット

• 耐障害性
  • 設定なしにサービス間通信に対して、耐障害性の仕組みが入る
    • 自動リトライ：NW障害や503エラー時に、Proxyレイヤで別タスクに自動リトライ
    • 外れ値検知：リクエストエラーが連続した場合、ルーティングから一定期間除外
• 過観測性
  • ServiceConnectProxyが収集するリクエストに関する以下のCloudWatchメトリクスが利用可能
    • 自サービスに関するリクエスト関連
    • 呼び出し先サービスに対するリクエスト関連（REDに関わる）
• 堅牢なデプロイ
  • Amazon ECSのローリングアップデートをサポート
  • コネクションドレイニング（コネクションの排出）によるダウンタイムなしのデプロイ
  • Cloud Mapを利用することでDNS TTLの影響を受けない高速なデプロイ

これからのサービス間通信の選択肢

• ロードバランサー有
  • 1. Elastic Load Balancing (ELB) → 外部からアクセスさせたい。 B/Gデプロイを利用したい場合。
• ロードバランサー無
  • 1. Amazon ECS service discovery → プロキシを利用せずに個別実装で信頼性をを導入する場合
  • 1. AWS App Mesh → 各種設定の閾値変更などの細かい通信制御の要件がある場合
  • 1. Amazon ECS Service Connect [new] → サービス間通信で信頼性を重視する場合のファーストプライオリティ

まとめ

• サービス間通信では耐障害性と過観測生の実装が重要
• 今までは3つの選択肢だったが、ECS Service Connect により、シンプルな設定で高い信頼性を持ったサービス間通信を実現できるようになった
  • 耐障害性: 1. 自動リトライ/ 2.外れ値検知/3.接続タイムアウト
  • 可観測性: サービス間の RED メトリクス
  • 堅牢なデプロイ: ダウンタイム無しのデプロイメント

感想

本記事ではECS Service Connect についてご紹介しました。
昨年のre:Inventで発表されてから、気になってはいたものの使ったことない機能だったため、大変勉強になりました。

よりDeepDiveしたい方はこちらのAWS公式Youtubeやハンズオンが参考になると思います。

最後までお読みいただきありがとうございました！
どなたかのお役に立てれば幸いです。

以上、おつまみ（＠AWS11077）でした！